For carrying out any task, there are certain requirements which are perceived as necessary and essential for successfully accomplishing the task. These requirements may be inherent in the task to be performed, typically referred to as the problem domain or may be inherent in the implementation, typically referred to as the solution domain.
Business requirements describe in business terms what must be delivered or accomplished by an application to provide value. Product requirements describe the system or product which is one of several possible ways to accomplish the business requirements. Process requirements describe the processes the developing organization must follow and the constraints that they must obey. The product and process requirements are closely linked. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement for the product to be maintainable (a product requirement) often is traced to by requirements to follow particular development styles (like object-oriented programming), style-guides, or a review/inspection process (process requirements).
A requirements specification is a complete documented description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the system. Use cases are also known as functional requirements. In addition to use cases, the requirements specification also contains nonfunctional (or supplementary) requirements. Poor requirement specification is a source of many defects in application development.
Different apparatus and methodologies are known for the development of applications. For instance the Rational Unified Process (RUP) prescribes a Use Case-driven approach and defines views for application development. This method addresses software development lifecycle (SDLC), and is very comprehensive. It is a UML (Unified Modelling Language) based method that promotes a use case centric approach. However RUP does not explicitly state or recommend any mechanism to identify a complete set of use cases. The granularity at which a use case should be defined is also left to the choice of an RUP user. There are no specific guidelines on how to ensure completeness and correctness of the use case model arrived at or on establishing consistency between requirements gathered from multiple stakeholders. [Philippe Kruchten, The Rational Unified Process—an Introduction, Addison-Wesley, 1999. 10(4): 13-16, 1997.]
Similarly, the KAOS (Knowledge Acquisition in Automated Specification) approach presents a goal-oriented requirement elaboration method. The method goes by the route of identification, structuring, refinement and formalization of goals. KAOS focuses on formal refinement of high-level goals into system constraints meant as functional requirements. [Axel Van Lamsweerde, Goal-Oriented Requirement Engineering: A guided Tour, Proceedings RE'01, 5th IEEE International Symposium on Requirements Engineering, Toronto, August 2001, 249-263.]
Yet another apparatus and method, the Enterprise Knowledge Development (EKD) is a refinement of Enterprise Modelling to accommodate change management. The focus here is on alternate scenarios for change and selection of the most appropriate one. These are goal-driven approaches and they focus largely on the enterprise modelling part of application development [Kerry Raymond, Reference Model of Open Distributed Processing: Introduction]
Another method, ‘The Reference Model of Open Distributed Processing—RM-ODP’ also uses the notion of viewpoints for this purpose. These are goal-driven approaches and they focus largely on the enterprise modelling part of application development. [Colette Rolland and Naveen Prakash, From Conceptual Modelling to Requirements Engineering, Annals of Software Engineering, 10, 151-176, 2000. This method too lacks explicit focus on requirements.
‘The Zachman framework’ organizes development processes around the points of view taken by the various players in the business environment and the things they must take into account and represents each of these as cells in a matrix. [J. A. Zachman, A Framework for information systems architecture', IBM Systems Journal, vol 26 no 3, 1987]. This framework does not have an explicit focus on requirements and does not take into account the complete software development life cycle and therefore does not offer any specific guidelines in the process of application development and planning.
All of the above approaches have a consensus on the fact that requirements must be done right, but they do not recommend any approach that addresses the ‘how’ part. How do we make requirements better in terms of consistency, completeness and correctness is still left to the practitioners of the method. Most of the tools in requirements space address requirement management problem—which means they assume that requirements are in place and they only need to be managed better. But in reality, the problem starts at a much earlier stage, at the stage of requirements definition itself.
Therefore there is a need to have an approach that explicitly addresses different types of requirements and offers clear and specific guidelines to meet them through a machine implementable solution.
U.S. Pat. No. 6,571,247—Danno et al describes a method to generate object design information. Resources and business activities to be performed in a business need to be entered hierarchically to generate the design information The disclosure of U.S. Pat. No. 6,571,247 covers only the analysis and design aspects of application development.
U.S. Pat. No. 6,745,381—Ehnebuske et al describes a method and notation to enable an explicit distinction between static and dynamic features of object-oriented models. The methodology does this during the modeling process by capturing the decisions to allow for business driven variability as explicit diagram annotations called control points. The business variable portions of the system of interacting objects are simultaneously captured as objects called business rules.
U.S. Pat. No. 5,996,012—Jarriel et al describes an application builder to generate a configuration management application for use in a computing environment. Application developer creates prototyping data for a particular management application. The prototyping data is used to generate a prototype application.
But there is felt a need for a business process automation system which can generate an executable optimized requirements set which                provides requirements driven application development approach;        separates the problem domain and solution domain clearly and identifies four distinct contexts for capturing, analyzing, modeling and prototyping requirements in the course of application development;        renders agility to application development;        provides reliable verification and validation;        makes the application to be delivered with minimal errors using feedback and requirement enhancement.        